PREFACE 



This Paper is essentially a progress report on the simultaneous 
use of on-line, time-shared JOSS computer consoles at The RAND 
Corporation. It covers activities implemented during the past six 
months by this writer and other members of the RAND staff. It is a 
preliminary report in the sense that large scale applications of the 
concepts presented herein will take place in the near future, but ex- 
tensive gaming results are not yet available. It is a progress report 
in the sense that most of the groundwork (programming) has been com- 
pleted and tested and it is possible to state categorically that the 
basic concepts work. Man-machine gaming situations and simulations 

Throughout this Paper the use of The RAND Corporation's JOSS 
System in on-line, time-shared multiconsole gaming and simulation is 
described in considerable detail. Naturally, other on-line, time- 
shared computer systems are commercially available. In some cases 
they may be superior to the JOSS System. Unfortunately, time has not 
permitted a comparison of the advantageous features of different com- 
puter systems. However, the reader should bear in mind that neither 
the JOSS System nor the techniques described herein are being extolled 
as the best or preferable way to accomplish the task of bringing close 
together computer power and the human participants in games or simu- 
lations. To reiterate the opening statement, this Paper is a progress 
report of what has been accomplished. It is left to the reader to con 
jecture how far we can go in the applications of on-line, time-shared 
computer consoles in games and simulations, and how advantageous this 



JOSS is the trademark and service mark of The RAND Corporation 
for its computer program and services using that program. 



ABSTRACT 



Some present-day on-line, time-shared, multiple-console computer 
systems provide for use of a common file system. One console can file a 
message (i.e. , "information") which can be recalled by another console. 
By programming consoles to periodically interrogate certain files, a 
crude, but highly serviceable, store-and-forward communication system 
can be created and large numbers of on-line , time-shared computer con- 
soles can be used to enter, recall, process, and display information 
typical of that used in command and control systems and the play of 

The RAND Corporation's JOSS System provides the capability described. 
In addition to its use for the solution of scientific problems , it is 
presently being employed to simulate in real time elements of an auto- 
mated tactical air control system and in the play of tactical games and 
games of global strategy. The simple, easy-to- learn programming lan- 
guage makes feasible considerable experimentation with scheduling al- 
gorithms , decision rules, etc. 

This Paper describes the basic features of the use of multiple 
JOSS consoles in simulation and gaming and discusses some of the ad- 
vantages , limitations, and lessons learned to date. 
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I. INTRODUCTION 

The need for data automation as an aid to real-time or near real- 
time system simulation and gaming is a long-standing one. Past efforts 
have seen many applications of digital computers in this area/ 1 ' 2 ) 
In general, however, there has been an inherent difficulty in applying 

of strategy involving both men and machines operating in real-time. 
The difficulties in applying digital computers in the past derived in 
part from the lack of computational speed, the complexities of pro- 
gramming languages, and the batch operation feature (single input, 
single output) of most computers of that period. 

To perform simulations and gaming in real-time or near real-time, 
it has long been recognized that all participants, including the con- 
trol group, have need for continuously available computer power. The 
system should also be capable of performing the functions of a store- 
and-forward communications system so that actions taken by one party 
can--at the direction of the initiator or as an inherent function of 
the nature of the action--provide raw and/or processed information to 
all other affected parties in the game or simulation. The computer 
power provided to the participants needs to be of sufficient speed and 

Any views expressed in this paper are those of the author. They 
should not be interpreted as reflecting the views of The RAND Corporation 
or the official opinion or policy of any of its governmental or private 
research sponsors. Papers are reproduced by The RAND Corporation as a 
courtesy to members of its staff. 

This paper was prepared for presentation at the National Gaming 
Council Symposium, Washington, D.C. , June 8, 9, 1967. 



storage capacity so that each participant in essence can employ programs 
that provide him with information or capability at least approximately 

tions and display equipment that might exist in an actual situation. 

Today's third generation digital computers, programmed and con- 
closely approximate the general requirements outlined above. Obviously, 
the many various equipment arrangements and programming languages that 
are presently available provide many degrees of capabilities in each of 
the simulation and gaming needs suggested. 

paper describes briefly some of the characteristics of The 
RAND Corporation's JOSS System --'an on-line, time-shared computer 
presently providing service through 34 consoles. The basic character- 
istics of the JOSS System storage file configuration make it possible 
for one console to command the entering of information, either textual, 
both, into a file-item that can be accessed by programs under 
rol of any other console in the system. This feature permits 
of the JOSS System as a crude, but serviceable, store-and- 

-ng. 

i recently developed applications of the JOSS System to multi- 
on-line simulation and gaming are discussed herein. The first 
n presented puts the JOSS System in the role of message hand- 
BLUE-RED game under control of GREEN (the referee). Although 
data processing does not take place in this game, it can 
added in the future. A two-party battle between missile- 

md application. The third application is a simulation of some 
»f the close air support role of a hypothetical automated tacti- 
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The role played by a modern multiconsole , on-line, time-shared 
computer In simulation and gaming is by no means limited to the illus- 
trative applications given in this paper. As noted above, necessary 
ingredients tend to be large computer power, mutual accessibility of 
files by all consoles, and a convenient, easy-to-use programming lan- 
guage. While all of these features are important, the last is probably 
most nearly paramount, for it is the feature that permits the real users 
of the system to improve and improvise rapidly and easily as the devel- 
opment of the game or simulation progresses. Fortunately, these three 
basic system elements are available today. And it is probably safe to 
say that future applications of on-line, time-shared computers in games 
and simulations will be widely varied, extensive in scope, and very 
imaginative. 



"Computer power" is considered here to be large when 1) the com- 
puter has the capability to perform the basic add-subtract operation 
in no more than a few microseconds; 2) there is "sufficient" high speed 



II, THE JOSS SYSTEM 



RAND's JOSS System was first implemented on the JOHNNIAC computer 
(now residing in the Los Angeles County Museum) by J. C. Shaw, to whom 
principal credit must go, both for design and construction. Beginning 
with partial operation in early 1963 and progressing to full capability 
with 8 on-line consoles in January 1964, the present JOSS System has 
been succinctly described by G. E. Bryan in a recent paper: ^ 

JOSS is a time-shared computer system that provides for 
the solution of numerical problems via an easily learned 
language at remote typewriter consoles. The PDP-6 hardware 
used to implement JOSS consists of 32,000 words of 1.75p,sec 
core memory, a 1-million-word 4+isec drum, a 6-million-word 
discfile, and various peripheral devices. A special data 
relocation mode for memory references has been added to facili- 
tate interpretation of JOSS programs. The JOSS consoles, built 
around a Selectric I/O typewriter, were specially manufactured 
to RAND specifications. Features include full duplex signaling, 
line parity checking, a page ejection mechanism, and several 
buttons and lights to control and report console status. The 
stand-alone JOSS software consists of the JOSS language inter- 
preter and its arithmetic subroutines , a monitor for user 
scheduling and resource allocation, and I/O routines for the 
disc, drum, consoles, and other peripheral devices. JOSS 
service is currently available to nearly 500 users through 
34 consoles, six of which are remote to RAND operating over 
both private and dataphone lines. 

For the purposes of real-time gaming and simulation, the JOSS 
language is sufficiently close to conventional English to permit the 
user to begin writing some parts of the programs needed for simulation 
and gaming after only a few minutes of instructions. The JOSS System 
software provides a high degree of interaction (i.e., feedback) with 
the programmer during the course of writing the program, facilitating 
on-line programming, and program checkout and debugging. Each command 
is tested by the JOSS System for certain programming requirements , 
and it is also possible to ask JOSS (JOSS users often refer to the 
System collectively by the personal pronoun) to execute each line or 
a given group of lines of instruction to test for validity. 

In the Fall of 1966, JOSS System software designers added a feature 
that makes possible the use of many consoles in a simultaneously inter- 
active mode, and, thus, makes JOSS suitable for multiconsole games and 
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simulations. The added feature was the ability to do filing, recalling, 
and discarding of information under program control. Since all consoles 
share a common disc file, this feature carries with it implicitly the 
ability for all consoles to jointly interact with the same file. They 
must do so, of course, sequentially. At present, the techniques for 
sequencing and timing file actions needed to avoid conflicting file 
usage are left to the programmer (the user of JOSS). In the near 
future it is expected that more appropriate features will be added to 
the JOSS System software and will become available to all JOSS users. 

A typical example of the use of a JOSS file and the repeated in- 
terrogation of a JOSS file-item is shown in Fig. 1. This figure also 
gives a good illustration of the ease with which JOSS programs can be 
written by even the newly initiated. The flow diagram for the program 
(part 1, in JOSS language) of Fig. 1 is shown in Fig. 2. With the help 
of the flow diagram it should be apparent that the program permits the 
user to enter the file and then repeatedly interrogate the file-item 
(item 5 (MS AGE) ) where it is anticipated that some other user will have 

The message is assumed to be composed possibly of data, or text 
and data, or text, in conjunction with an identifyine parameter . "k," 
whose numerical value signifies the message type. For example, k = 0 

data, and k = 3 signifies that only text is present. The text is as- 
sumed to be written as "part 10," thus it can be passed around through 
the system under that general designation and typed out (displayed) at 
any desired point. For the cases where the message includes data, the 
designated program (part 2 or part 3) would process the data and display 
results for the message recipient. As shown in Fig. 2, part 2 or part 3 
would return to message monitoring. However, other options are also 
possible. 



Ultimately, it is to be expected that JOSS will become a full 
and equal gaming partner, signaling other consoles, making his own 
decisions, and having his own suspense file. 
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.1 Use file 234 (syopt). 

.2 Recall item 5 (MSAGE). 

.21 To step 1.7 if k = 0. 

.3 Do part 2 if k = 1. 

.4 Do part 3 if k = 2. 

.5 Type part 10 if k = 3. 

.7 Do step 1.72 for n = 1(1)2000. 

.71 To step 1.8. 

.72 Set n = n. 

.8 To step 1.2 if k = 0. 

.81 Set k = 0. 

.82 Discard item 5 ( MS AGE ) . 

.83 File k as item 5 ( MS AGE ) . 

.9 To step 1.2. 



Fig. 1 — Typical JOSS program for message interrogation, 
decision, and time delay. 
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Fig.2— Flow diagram of typical interrogation, decision, and time 
delay JOSS program 
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III. MULIICONSOLES IN A TEXT-ONLY WAR GAME 

The file-item Interrogation program of Fig. 1 can be combined with 

sential features of a store-and-forward communication system suitable 
for passing messages back and forth between two combatants in a war 
game in which, for example, diplomatic exchanges are the principal 
feature. A schematic outline of a simple two-player configuration is 
shown in Fig. 3. The use of the start-up routine is shown in Fig. 4 
and the salient features of the message generation program are illus- 
trated in Fig. 5. ' The three simple programs needed to provide this 
level of gaming capability are given in Appendix A. 

For the more interesting game applications, the exchange of mes- 
sages between BLUE and RED would be monitored and influenced by the 
referee, GREEN. The basic start-up, message generating, and interro- 
gation program of Appendix A can be modified somewhat to permit BLUE- 
RED messages to be monitored simultaneously by GREEN, and to afford 
GREEN the ability to send private messages to BLUE or GREEN. The 
fundamental structure of such a console configuration is shown in 
Fig. 6. 

In this instance, six file-items have been used as intermediate 
storage points for messages from the participants. This ensures, for 
example, that BLUE action in response to a message from RED will not 
prevent GREEN from getting a copy also. As indicated in the figure, 

the message receiving mode and a second in the message transmitting 
mode, thus assuring up-to-the-minute knowledge of all communications 
between BLUE and RED, without slowing preparation and transmission of 
GREEN messages. 

"Console user inputs appear in green type; JOSS responses appear 
in black type. This feature of the JOSS System is used throughout 

**Because the operations performed by GREEN are slightly different 
from those executed by BLUE or RED, GREEN uses slightly modified versions 
of the start-up, message generating, and interrogation programs that are 
jointly used by BLUE and RED. These six programs are given in Appendix B. 
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Fig. 3— Typical two-party JOSS store-and-forward 
communication system configuration 
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Use. file 233 (syop3). 
Recall item 1 (COMM1). 
Do part 10. 

JOSS Store-and-Forward COM-SYSTEM Start-up Program. 



Give item no. to which your messages are to be transmitted. 
T = 3 

Give item no. from which you will receive messages. 

R = 5 

To begin operation in the RECEIVE mode, type K = '0*. 
To begin operation in the TRANSMIT mode, type K = '1'. 

END OF START-UP PROGRAM. 



Fig. 4— Use of JOSS start-up program 
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MESSAGE GENERATION AND TRANSMISSION PROGRAM. 



After composing message, type "Go.". 
Stopped by step 100.4. 

' I TIME = 11:42 hrs 

> FIRST MESSAGE FROM RED TO BLUE: 
>1 

) SBSB BLUE military actions in the vicinity of HUMDRUM PASS 

)1 Represent a violation of our borders. RED military forces 

12 are retaliating against fiillJE«airbases and military installations 

13 within 200 n mi of HUMDRUM PASS. 

; requested an immediate 

'1 SIGNED: First Premier of RED- LAND 

. TIME = 11:42 hrs 



2 FIRST MESSAGE FROM RED TO BLUE: 
21 

3 BLUE military actions in the vicinity of HUMDRUM PASS 

31 represent a violation of our borders. RED military forces 

32 are retaliating against BLUE airbases and militarv installations 

33 within 200 n mi of HUMDRUM PASS. 



t Premier of RED-LAND 



To make CORRECTIONS, set C = '1', else set C = '0'. 
MESSAGE TRANSMITTED. 

To shift to MESSAGE MONITORING mode, set k = '1'. 
To send ANOTHER MESSAGE, set K = '0 1 . 

Entering the MESSAGE MONITORING mode. 



Fig. 5— Use of JOSS message generation and transmission program 
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T(l) = ll=GREEN-to-BLUE 
T(2) = 10 = GREEN-to-RED 



R(l) = 15 = BLUE-to-RED 
R(2) = 13 = RED-to-BLUE 



R(2) 
R(l) 



RED 



T(l ) = 12=RED-to-BLUE 

T(2) = 13 = RED-to-BLUE (to GREEN) 

R(l ) = 14 = BLUE-to-RED 
R(2) = 10=GREEN-to-BLUE 



BLUE 



T(l ) = 14 = BLUE-to-RED 

T(2) = 15 = BLUE-to-RED (to GREEN) 

R(l ) = 12 = RED-to-BLUE 
R(2 ) = 1 1 =GREEN-to-BLUE 



Fig. 6— Typical BLUE-RED-GREEN wargame JOSS configuration 
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IV. MULTICONSOLES IN A SUB -LAUNCHED MISSILE DUEL 

To develop background Information for the use of the JOSS System 
in war gaming at RAND, C. F. Black and D. C. Kephart have structured 
programs for a simulated battle between two missile firing submarines-- 
extending the two-console "JOSS-SPIEL" game initially formulated by 
T. A. Brown. This is a two-player game, with each player given a 
trade-off choice of four combinations of maximum sub speed and a num- 
ber and range of missiles. A player does not know initially what capa- 
bilities his opponent has chosen, but as the game progresses it may be 
possible to infer this. 

The two players operate within a hypothetical 100-by-100 n mi 
square of ocean. The hypothetical sub-launched short range missiles 
are assumed to have a kill radius of 2 n mi and a maximum range of 60 
or 75 n mi , depending on the model. Each player also positions 4 
nuclear mine fields (4 n mi damage radius) in the square. The players 
then input the position, heading and speed of their submarines and the 
game begins. A list of game rules is given in Fig. 7. 

The program carries the play through in assumed 15-minute time 
intervals of action. Random number generators are used to create un- 
certainty in knowledge of the location of the opponent and in the reli- 
ability of missile launch. 

trial "flag" is set to zero at the beginning of the game and incremented 
by the opponents as play progresses. The value of the flags must be 
equal before play can move to the next stage. Figure 8 shows a sche- 
matic of the submarine game operation. 

The play is continued at a reasonable pace by using the timer 

only two minutes to choose a new course heading, new speed, and fire 

The two players make their moves essentially simultaneously. After 
both players have specified their actions for the next 15-minute inter- 
val, the various parts of the program are activated and the results 



Missile kill radius =2 



o Damage radius = 4 n mi (missiles and minefields). 

o Damage: Your speed and maneuver controls are locked at present values. 
Fire control stays operable. 

o Damage + damage = kill . 

o You get 2 minutes real time to maneuver your boat and launch missiles, 

o Salvo limit = 3 missiles, 

o Missile CEP = 0. 

o Missile range = 60 n mi (except mod 1 = 75 n mi) . 

o Accuracy of sensor fix on enemy: 

Range: ± 10 percent as perturbed by a random number. 
East and North coordinates: + 10 percent of range. (Each coordinate 
independently perturbed by a different random number) . 

o 50 percent speed penalty to execute a course reversal. 

25 percent penalty for 90-deg turn. Others in proportion. 

o Each time interval covers 15 minutes of operation. 

o Zero speed for 15 minutes if you run aground while undamaged. 

o You can slip through a minefield — as long as you are not still inside 
the minefield at the end of a 15-min step interval. You can be 
clobbered twice in the same minefield if your speed is slow enough. 

o Missiles targeted to impact points beyond range are lost due to 

o Your commitments are final once you hit the JOSS "RETURN" key. 

o You get no damage report on the enemy. You might deduce his status 
by observing his maneuvers. 

o Missile launches should be targetted against expected enemy location 
15 minutes after launch. 



Fig .7 — Rules for the two-player hunter-killer submarine game 
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Id data. 
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1 
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when 


data 
T r =T b 



Discard old data. 



Discard c 
T b =' 


Id flag. 
b+ I 9 






Recall flag 


1 


Recall 


Tb = T r 



Set T r =T r + l 
Process data . 

Type situation. 

Make decisions. 



Set T b = T b +l 
Process data. 
Type situation. 
Make decisions. 
Insert new data. 



Fig. 8— JOSS submarine battle simulation: data channels 
and action sequencing 
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step T do not impact until T + 1 (a 15-minute game cycle later), then 
each submarine has an opportunity to avoid both enemy and own shots , 
and players must make a "lead" allowance in targeting the opponent. 
Figure 9 shows an initiation of game play, as seen by BLUE. 

Because of the flexibility of the JOSS language, it has been pos- 
sible to make the programs very general: with little additional effort, 
new decision rules and weapon systems, such as torpedoes, depth charges, 
active and passive acoustic sensors , ocean depth constraints , and com- 
munications links (including links between adversaries) could be added. 
With additions such as these, this and similarly structured games (tank 
battles, surface ship conflicts, etc.) could be useful both In devel- 
oping tactics and as a training aid for actual weapon system users. 
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)o cart 10. 

::" :: HUNTER KILLER NUCLEAR SUBMARINE ENCOUNTER :: :: 




0 Time:1200 Your position: 70 East, 50 North. 

Speed: 53 kts, Course: 315 deg. 



Fig. 9— Hunter-killer submarine game: BLUE printout 
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[2] RECESS 1600-1800 PDT 



Time: 1215 Yoi 



c position: 61 East, 59 North. 
Speed: 53 kts , Course: 315 deg. 



: : : : FLASH : : : : 
ENEMY CONTACT *** ENEMY CONTACT : : : BATTLE STATIONS ::: 

ENEMY RANGE 15 mi. ENEMY POSITION 2t EAST, 32 NORTH 



You have 2 minutes to maneuver and launch missiles. 
Give COURSE Command: 

Give SPEED Command: (percent of max. speed) 

p = 100 
You have 7 missiles. 

Give aim coords, (E,N). E = 111 if done. 



50 sec 



E = 
N = 




1't find the requii 



Fig.9(conO— Hunter-killer submarine game: BLUE printout 
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2 Time:1230 Your position: 61 East, 71 North. 

Speed: 46 kts, Course: 0 deg. 

ENEMY RANGE 55 mi. ENEMY POSITION 35 EAST, 23 NORTH 

:: ENEMY ATTACKING :: 
::: BLAM ::: 

You have 2 minutes to maneuver and launch missiles. 
Give COURSE Command: 
c = H5 

Give SPEED Command: (percent of max. speed) 
You have 6 missiles. 

Give aim coords, (E,N). E = 111 if done. 

E = 111 



3 Time: 1245 Your position: 69 East, 79 North. 

Speed: 46 kts, Course: 45 deg. 
EMERGENCY::::: He have Reactor Trouble. 
Maximum Speed reduced to 41 knots. 

ENEMY RANGE 78 mi. ENEMY POSITION 31 EAST, 16 NORTH 



d launch missiles. 

Give SPEED Command: (percent of max. speed) 
p = 0 

You have 6 missiles. 

Give aim coords, (E,N). E = 111 if done. 

E = 111 
Status: RED ALERT. 

Error at step 9.4: I can't find the required item. 



Fig. 9 (cont.)— Hunter-killer submarine game: BLUE printout 
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V. MULTICONSOLES IN THE SIMULATION OF 
AN AUTOMATED TACTICAL AIR CONTROL SYSTEM 




COMMAND AND CONTROL IN THE PRESENT SYSTEM 

The relationship of the present Tactical Air Control System and 
the U.S. Army units it supports is shown in Fig. 10 for a typical Army 
corps area of responsibility in a joint task force operation. The 
corps front, or Forward Edge of the Battle Area (FEBA) , might be 20 to 
60 miles in width. The corps consists of at least two divisions; in 
Fig. 10, two divisions are on the FEBA and a third is in reserve in 
the rear. Each division contains three brigades and each brigade, 
three battalions. The Air Force probably would provide air defense 

Control and Reporting Post (CRP) , etc. , as shown in the lower left of 

Control Center (TACC) associated with the Air Force Forces Command 
Post (AFFCP) and a Direct Air Support Center (DASC) operating in con- 
junction with the Army's Tactical Air Support Element (TASE). Other 
Army command elements include the Corps Tactical Operation Center (CTOC) 
and the Army Forces Command Post (ARFCP) . (The ARFCP , CTOC, DASC, and 
TASE essentially form the Corps Headquarters.) 




Fig. 10— Present Tactical Air Control System 
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SIMULATION OF AN AUTOMATED TACTICAL AIR CONTROL SYSTEM 

the Tactical Air Control System just described is evident. Data auto- 
mation could handle much of the message routing, status updating, etc. 
In short, many of the tasks that are now performed manually could 

infeasible today should become possible. 

for the Tactical Air Control System, is the development of a digital 
message entry device suitable for use by Forward Air Controllers. The 
U.S. Air Force tested a Digital Message Entry System (DMES) in early 
1966 with generally favorable results/ 5 ^ 

will be the employment of a computer to process the requests for re- 
sources in terms of the resources available. In the case of FAC re- 
quests for close air support (CAS), the decision point is the Fighter 
Duty Officer (FDO) in the DASC. It is this facet of an Automated 
Tactical Air Control System--FAC, BASE, and DASC--that has been simu- 
lated using the JOSS System and will be discussed below. 

The digital message entry device tested at the Tactical Air Warfare 
Center in 1966 is shown in Fig. 13. The message format of this device 
has been used in the JOSS simulation. Provisions have been made in the 
simulation programs for requests for resources from six FACs and status 
of resources from four airbases , as shown in Fig. 14. A single console 
serves the DASC FDO. The DASC program monitors the store-and-forward 

quest is received, the FAC message is automatically printed, followed 
by a listing of the resources available at the four airbases. The FDO 
is then afforded an opportunity to assign flights of aircraft to meet 
the request. Flights may be assigned from any or all airbases. Once 

gram automatically sends the assignments and the FAC request (for 




Fig. 14— JOSS ATACS simulation 
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information purposes) to all appropriate airbases. An acknowledgment, 
containing all flights assigned, is also sent to the requesting FAC. 
These features are illustrated in Fig. 15. 

At the airbases where an assignment has been made, the status of 
available aircraft is automatically updated, so that the next time the 
DASC receives a request, the latest status of available resources will 
no longer have the previously assigned flights showing. 

Once the FAC has received his acknowledgment from the DASC, his 
program automatically prepares for him a blank CAS request form which 
can be filled in with pencil before formally inserting the message 
into the system. 

As initially programmed, the ATACS simulation uses all 25 file- 
items in a single JOSS file, allocated as shown in Fig. 16. The store- 
and-forward communications portion of the simulation--in this case 
handling only numerical data— occupies 20 of the file items , with the 
DASC, BASE, and FAC programs and other housekeeping features filling 
the remaining 5 file-items. The various interconnections of the 11 
JOSS consoles through the medium of the common file are shown in Fig. 17. 

AN ILLUSTRATION OF THE ATACS SIMULATION 

The system simulation just outlined is easily illustrated by 
running through a sequence of operations that might occur at the vari- 
ous consoles. Figure 18 shows the close air support form filled in by 
the FAC, both in pencil and then input to the console. The FAC simu- 
lation program is designed to offer the FAC as many opportunities as 
needed to make corrections in the message, since human error at this 

The BASE program has routines that permit operation in a DASC 
monitoring mode, or a status input mode, or a status correction mode. 
Figure 19 shows the "educational" routine that can be called out by a 
new operator to provide background information on the operation of the 
programs. Normally, of course, all this Information is not necessary 
for a well-practiced operator. Figure 20 presents an airbase status 
report consisting of three flights that has been inserted, checked, and 
stored in the status file-item for Nha Trang airbase. As in the FAC 
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FACs 

BASEs _ 




Fig. 15 — ATACS automatic AIRBASE assignments 
and FAC acknowledgment 



FILE 232 (SYOP2) 



FAC "TRIGGERS" 



AIRBASE STATUS 



FAC REQUESTS 



AIRBASE ASSIGNMENTS < 



PROGRAMS, ETC. 



1 k =0,1 


2 


k =0,2 




3 k =0,3 




k =0,4 




5 


k =0,5 




6 


k =0,6 




7 


"B-LIST " 


(TAN SON NHUT) 


8 " (NHA TRANG) 


9 




(BIEN HOA) 


10 




(CAM RANH BAY) 


11 "A-LIST" 


12 


13 


14 


15 


16 


17 


"C -LIST » 


(TAN SON NHUT) 


18 " (NHA TRANG) 


19 




(BIEN HOA) 


20 




(CAM RANH BAY) 


21 


TEMP 




22 


DASC 




23 


BASE 




24 


FAC 




25 


DATA 





Fig. 16— JOSS ATACS file usage 
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Fig. 17 — JOSS ATACS message switching 



14:18 5/11/67 #45 GMN 1423 [21 rfcf« 

L2j RECESS 1600-1800-SYS MARGINAL 

1 ^ 

0025c' AIR SUPPORT REQUEST NO. 

Target Location No.^J | l=XU 2=YU 3=ZU 4=ApfJ^BP) 6=XT 7=YT 8=ZT 9=AN 0=BN] 
Target Coordinates :^lj[ RIGHT ^Jt\ W 

TIME ON TARGET [Desired] ft°> OP TIME ON TARGET [Latest] V°l 
TARGET TYPE 4~ QUANTITY 3 

l=Tnks 2=Bnkrs J 2=fiun Pos (jT=VehcT^ 5=Brdge 6=Trps 7=Supls 8=CP 9=Ammo 0=P0I 
1=1-5 2=6-10 Ci=l 1-20) 4 = 21-30 S=31-40 6=41-50 7=51-100 8=BATT 9=BRIG 0=DIV 
DESIRED RESULTS ^ [1=DESTR0Y 2= INTERDICT 3=NEUTRALIZE 4=HARASS] 



WHEN READY TO INPUT NEW REQUEST, TYPE 'K = 1'. 

Code; M. Type; M. No. 
A(l) = 47 

A(3) = 4 

A(5) = 473 
A(6) = 261 

Time: 

A(7) = C9C0 
A(8) = 0945 
Tgt.: Type; Quan.; Res. 

A(10) = 3 
A(ll) = 1 

For corrections, type 'K = 1', otherwise, 'K = 0'. 

K = C 

00247 AIR SUPPORT REQUEST NO. 4 

TGT. LOC. No.= 5 COORDS: 473 RIGHT 281 UP 

TIME ON TARGET [Desired] 900 TIME ON TARGET [Lat 

TGT. TYPE-4 QUANTITY- 3 DESIRED RESULTS-1 

Type your FAC Number to input FAC REQUEST. 
Trigger No. 1 is set. File-item 11 is updated. 



Fig. 18— Forward Air Controller request for close air support 



[t] RECESS 1600-18C 



For 



AIRBASE IDENTIF 
iSE I DENT, type 



AIRBASE IDENTIFICATION 
Tan Son Nhut Airbase: Set f = 
Nha Trang Airbase: Set f = 

Eien Koa Airbase: Set f = 

Cam Ranh Bay Airbase: Set f = 



For STATUS REPORT key, type 'k 
k = 1 

KEY TO AIRCRAFT STATUS REPORT 
1 = Beginning line number. (Don' 
L = Last line number. (L-l+1 = 
" e of STATUS REPORT 



= Data Line Number 

= Squadron Number 

= Mission Identification Number 

= Number of Aircraft in Alert Flight 

= Type Aircraft in Alert Flight 

= Call Sign Identification Number 

= Time Aircraft Go On Alert Status 

= Mission Type Identification Number 
i Load Identification Number 



L SIGN, MSN T 



Mission Types: 1 = INTERDICT; 2 = 
ORDNANCE LOADS 
1 = Guns, AIM-9/B 



Napalm, 2.75 in R 
Napalm, 750 lb GP 
750 lb GP Bombs, 



Napalm, CBU 
AGM-12B 

500 lb Frag Bombs 
Napalm, 500 lb Frag B 



input a STATUS REPORT, type 



Fig. 19— BASE start-up and "educational" printout 



+ :29 5/11/67 #H5 GHN 1423 [5] RECESS 1600-1600— SYS MARGINAL 



r Corrected Lines) 



line number? 



Fig. 20— BASE alert flight status input 



14:32 5/11/67 #45 GKK 1423 



Alert T 
B(2 



E of this STATUS REPT. 



: transmitting data? 



ALERT AIRCRAFT STATUS REPT: N 
STATUS REPORT TIKE 



[A TRANG Airbase 
1432 HRS 



(3) (4) (5) (6) (7) (8) 
MSN NO. TYPE CALL TIKE MSN 
NO. A/C A/C SIGN AVAIL TYPE 



Corrections? Type ' 



THIS DATA HAS BEEN STORED IN FILE-ITEK 



THIS MACHINE IS NOW IN THE DASC HON ITO RING LOOP. 



Fig. 20 (cont.) — BASE alert flight status input 



14:37 5/11/67 #45 GKN 1423 [9] RECESS 1600-1800 — SYS MARGINAL 



MESSAGE FROM FAC No. 1 

For FULL FORMAT, type 'k=l', for SHORT FORMAT, 'k=0'. 

k = 1 

00247 AIR SUPPORT REQUEST NO. 4 

Target Location No. 5 [1=XU 2=YU 3=ZU 4=AP S=BP 6=XT 7=YT 8=ZT 9=AN 0=BN] 
Target Coordinates: 473 RIGHT 281 UP 

TIME ON TARGET [Desired] 900 TIME ON TARGET [Latest] 945 
TARGET TYPE 4 QUANTITY 3 

l=Tnks 2=Bnkrs 3=Gun Pos 4=Vehcls 5=Brdge 6=Trps 7=Supls 8=CP 9=Ammo 0=POL 
1=1-5 2=6-10 3=11-20 4=21-30 5=31-40 6=41-50 7=51-100 8=BATT 9=BRIG 0=DIV 

DESIRED RESULTS 1 [1= DESTROY 2=INTERDICT 3=NEUTRALIZE 4=HARASS] 



AVAILABLE AIRCRAFT 



LINE SQD MSN NO. 
NO. NO. NO. A/C 



TAN SON NHUT TIME: 1230 hrs. 

•i F-100 1 



1 F-100 

2 F-100 



N. A. till 1000 h 



3 F-100 

4 F-100 
2 F-100 



CAM RANH BAY 



To assign aircraft, type 'k = 1', otherwise 'k = 0'. 
AIRCRAFT ASSIGNMENT PROGRAM 



Fig. 21— DASC response to FAC request 



llltO 5/11/67 »5 GKN 1*23 [10] RECESS 1600-1800-STS MARGINAL 



Select AIRBASE [f=l TSN f=2 NT f=3 BH f 
f = 1 

Select the NUMBER OF FLIGHTS: 

CU.0,0) = 1 
TO ASSIGN FLIGHTS, INSERT 'DATA LINE NUMBERS. 1 

C(1,0,1) = 3 
TAN SON NHUT AIRBASE ASSIGNMENT T 



type desired "f", othe 
f = 2 

Select the NUMBER OF FLIGHTS: 

C(2,0,0) = 1 
TO ASSIGN FLIGHTS, INSERT 'DATA LINE NUMBERS. ' 

C(2,0,l) = 2 
NHA TRANG AIRBASE ASSIGNMENT TRANSMITTED 



s AIRBASES, type desired "f", other 



Fig. 21 (cont.)— DASC response to FAC request 



14:46 5/11/67 #45 GMN 1123 [15] RECESS 1600-1800 — SYS MARGIKAL 



DASC MESSAGE FOLLOWS: 

THE FOLLOWING FLIGHTS ARE ASSIGNED CLOSE AIR SUPPORT 

LINE SQD MSN NO. TYPE CALL TIME MSN ORDN 
NO. NO. NO. A/C A/C SIGN AVAIL TYPE LOAD 
2 436 2 2 F- 4 5 900 2 9 



Now Updating Status Report. Give Present TIME: 

t = iki+6 

This BASE has 2 flights remaining. 

UPDATED STATUS REPORT HAS BEEN STORED IN FILE-ITEM 8 AT T = 1446 HRS 



FAC CLOSE AIR SUPPORT REQUEST FOLLOWS: 
00247 AIR SUPPORT REQUEST NO. 4 

Target Location No. 5 [1=XU 2=YU 3=ZU 4=AP 5=BP 6=XT 7=YT 8=ZT 9=AN 0=BN] 
Target Coordinates: 473 RIGHT 281 UP 

TIME ON TARGET [Desired] 900 TIME ON TARGET [Latest] 945 

TARGET TYPE 4 QUANTITY 3 

l=Tnks 2=Bnkrs 3=Gun Pos 4=Vehcls 5=Brdge 6=Trps 
1=1-5 2=6-10 3=11-20 4=21-30 5=31-40 6=41-50 7 " 

DESIRED RESULTS 1 [1= DESTROY 2=INTERDICT 

END DASC Message 



Fig. 22— DASC assignment message received by BASE 



IU-.U3 5/11/67 m5 GKN 1423 [12] RECESS 1600-1 



THIS MACHINE NOW AWAITING DASC RESPONSE 

(To input NEW REQUEST, "Interrupt" and type "Do part 1 



TAN SON NHUT: 



NHA TRANG: 



— SYS MARGINAL 



Fig. 23— DASC acknowledgement message received by FAC 



5/11/67 #45 GKN 1423 [1] RECESS 1600-1800-SYS MARGINAL 



Use file 232 (syop2). 
Roger. 

Recall iter, 22 (DASC). 

Do part 100. 

DASC PROGRAM START-UP: 

FAC No. 1 Trigger Set 

FAC No. 2 Trigger Set 

FAC No. 3 Trigger Set 

FAC No. 4 Trigger Set 

FAC No. 5 Trigger Set 

FAC No. 6 Trigger Set 



This Program "fetches"Data from File 234 (syop4) 



n BASE 
BASE No. 1 Status Updal 
BASE No. 2 Status Updal 
BASE No. 3 Status Updi ' 
BASE No. 4 Status Updi 
Data Fetch Program Finj 

FAC No. 1 Message 

2 Message 

3 Message 

4 Message 

6 Message 
All BASE Data Updi 



FAC No, 
FAC Nc 
FAC N< 



7,8,9,10 - File 232 (syop2). 



. All FAC Messages Inserted. 



DASC PROGRAM BEGUN. This machine will continue 
in a LOOP until FAC message is received, or until 
stopped by "INTERRUPT" action. 



Fig. 24— ATACS simulation "canned" demonstration start-up 
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in a single request the number of troops, gun positions, 
bunkers, vehicles, etc. , that might all be associated 
with a single target area.* 

The exercises fully illustrated the axiom that "the 
display of information can be one of the principal 
inherent pitfalls in any on-line computer-aided decision 
system. " 

It was found that the time required to receive and display 
a FAC request, display the BASE status reports, and al- 
locate resources to satisfy the request required from 
2-1/2 to 5 minutes. Much of this time was occupied by 
program-controlled typing. Even with the JOSS console 
Selectric typewriter, character-at-a-time display of 
information is exceedingly time consuming, in comparison 
with other actions required in the decision process. 
One concludes that it would be desirable to have infor- 
mation displayed simultaneously to the FDO on three 
separate CRT displays: one for the FAC request mes- 
sage, one for the BASE status information, and the 
third for the assignment message being composed by the 
FDO. 

A second conclusion is that an "overlay" keyboard— 
thus converting each console from general to special 
purpose — would be highly desirable. 

The JOSS simulation of the close air support feature 
of an ATACS was deemed sufficiently adequate to make 

developing experience and software prior to establishing 
requirements for the CAS feature of a field service 
computer-based system. JOSS-like on-line, time-shared 
systems offer the advantage that the various functional 
elements of an ATACS— close air support, reconnaissance, 
interdiction, air defense, and air lift/air assault— 

puter equipment. Of course , it is likely that the JOSS 
System per se might have trouble supporting all of these 
functions simultaneously in a complete, real-time 
simulation. 




VI. SUMMARY 



This paper has described several techniques and applications of 
RAND's on-line, time-shared JOSS multiconsole computer system to various 
facets of gaming and simulation. The JOSS System software character- 
istics that make possible the store-and-f orward communications feature 
among consoles—namely, common sharing of files and indirect file oper- 
ations—have only been available for seven months. During that time 
independent efforts at RAND have established the feasibility of using 
the JOSS System in multiconsole gaming and simulations by programming 
a strategic diplomatic exchange game and exercising a tactical battle 
game of the text-only and data-only type, respectively, and by pro- 
gramming and exercising a system simulation involving the classic triad 
of resource supply, requests for resources, and resource allocation, 
specifically applied to the close air support function of a hypothetical 
automated tactical air control system. 

Thus far, the principal result of this effort has been to gain 
experience and prepare and check out programs basic to future gaming 
and simulation activities of considerably larger scope. Even cursory 
experience with the hypothetical ATACS simulation has been sufficient 
to suggest that certain inadequacies in the DMED message format have 
been encountered and that there is considerable effectiveness at low 
cost in using a JOSS-like system to gain the insight and experience 
needed to properly specify requirements for computer hardware and soft- 
ware for systems such as an ATACS . 

The ease in programming afforded by a JOSS-like language ensures 

lation programming effort, both during the initial phases of writing 
programs and in the later--and often crucial— phases of revising and 
improving programs. The involvement of at least some of the game or 
simulation users at the basic programming level may result not only 
in greater understanding of the game/simulation structure by the users, 
but also may contribute considerably to reducing the amount of time 
needed to generate programs and program modifications. These features 
could result in a step-function improvement in game/simulation efforts 
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in the future, for, in general, these are features that have not been 
present in the past. 

It is not the intent of this paper to leave the reader with the 
impression that an on-line, time-shared JOSS-like computer system is 
a panacea for all the difficulties associated with computer-aided 
gaming and simulation. RAND's JOSS consoles are definitely output- 
limited in terms of the rate of presentation of information versus the 
ability of the human to absorb and use such information. But the mis- 
match is not great. If very extensive programs for numerical data 
processing and/or table look-up are required in running the game/simu- 
lation, experience indicates that, naturally, time-shared computers 
cannot match straight batch processing systems of comparable 

But the time-shared JOSS-like computer offers the opportunity to 
interconnect participants in a game/simulation without regard to location. 
For example, Type 33 and 35 Teletype consoles can, with certain minor 
limitations, be used as JOSS consoles. Conventional teletype or data- 
phone connections permit the internetting of JOSS consoles throughout 
the country. Features such as this, coupled with built-in store-and- 
forward communications potential, a simple and convenient I/O capability, 
and an easily mastered programming language may make on-line, time- 
shared multiconsole computers an integral and important part of many 
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JOSS PROGRAMS FOR A TWO-PARTY , TEXT-ONLY WAR GAME 



9:11 5/10/67 #13 GMN m23 [4] 



Type part 10. 

10.01 Type "JOSS Store-and- Forward COM-SYSTEM Start-up Program.". 

10.03 Type "Give item no. to which your messages are to be transmitted.". 
10.031 Demand T. 
10. 0H Line. 

10.05 Type "Give item no. from which you will receive messages.". 
10.051 Demand R. 

10.06 Line. 

10.07 Type "To begin operation in the RECEIVE mode, type K = '0'.". 

10.071 Type "To begin operation in the TRANSMIT mode, type K = '1'.". 

10.0711 Demand K. 

10.0712 Type "ERROR. K must be '0' or *1'." if K>1 or K<0. 

10.0713 To step 10.07 if K>1 or K<0. 

10.072 Line. 

10.08 Type "END OF START-UP PROGRAM.". 

10.081 Do part 2 if K = 0. 

10.082 Do part 100 if K = 1. 



Fig. 25— Start-up program for two-party, text-only war game 



9:10 5/10/67 #13 GHN 1423 [3] 
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Type part 2. 

2.0001 Type "Entering the MESSAGE MONITORING mode.". 

2.001 Recall item R. 

2.002 To step 2.2 if k * 0. 

2.003 Do step 2.005 for n = 1(1)5000. 
2.0031 Type "No message.". 

2. 004 To step 2.001. 

2.005 Set k = k. 

2.2 Page. 

2.22 Type "MESSAGE RECEIVED:". 

2.23 Type 

2.3 Type part 1 if k * 0. 
2.X Discard item R. 

2. 41 Delete part 1. 

2.5 Set k = 0. 

2.6 File k as item R. 

2.9 Type "END OF MESSAGE.". 

2.91 Type 

2.911 Type "To REPLY to above message, set K = '1',". 

2.912 Type "To continue in MESSAGE Monitoring mode, set K = '0'.". 

2.913 Demand K. 

2.914 Do part 100 if K = 1. 

2.915 To step 2.92 if K = 0. 

2.92 Type "Back in message monitoring loop.". 
2.99 To step 2.001. 



Fig. 26— Message monitoring program for two-party, 
text-only war game 



9:16 5/10/67 #13 GMN 1423 [6] 



Type part 100. 

100.001 Page. 

100.002 Type "MESSAGE GENERATION AND TRANSMISSION PROGRAM.". 

100.003 Type _, , . 

100.1 Set k = 1. - 

100.2 Type "Preface each line of message with a "Part 1" number.". 

100.3 Type "After composing message, type "Go.".". 

100.4 Stop. 

100.41 Type part 1. 

100.42 Type 

100.43 Type "To make CORRECTIONS, set C = '1', else set C = '0' " 

100.44 Demand C. 

100.45 To step 100.5 if C = 0. 

100.46 Type "Make CORRECTIONS , then type *Go.'.". 

100.47 Stop if C = 1. 

100.48 Type "To TRANSMIT message, set K = '1'.". 

100.481 Type "To CHECK message again for corrections, set K = '0'.". 

100.482 Demand K. 

100.483 To step 100.41 if K = 0. 

100.484 Line if K = 1. 

100.5 Discard item T. 

100.6 File k, part 1 as item T. 
100.61 Type "MESSAGE TRANSMITTED.". 

100.7 Delete part 1. 

100.8 Type "To shift to MESSAGE MONITORING mode, set K = '1'.". 
100.8001 Type "To send ANOTHER MESSAGE, set K = '0'.". 
100.801 Demand K. 

100.81 Do part 2 if K = 1. 

100.82 To step 100.001 if K = 0. 



Fig. 27— Message generation and transmission program 
for two-party, text-only game 




JOSS PROGRAMS FOR A BLUE, RED, AND GREEN TEXT-ONLY WAR GAME 



9:26 5/10/67 #13 GMN 1U23 [9] 



Type part 10. 

10.01 Type "JOSS Store-and- Forward COM-SYSTEM Start-up Program.". 

10.02 Type 

10.03 Type "Give item no. for storing messages to your opponent.". 

10.031 Demand T(l). 

10.032 Type "Give item no. for storing message copies for GREEN.". 

10.033 Demand T(2). 

10.04 Line. 

10.05 Type "Give item no. for receiving messages from your opponent.". 

10.051 Demand R(l). 

10.052 Type "Give item no. for receiving messages from GREEN.". 

10.053 Demand R(2). 

10.06 Line. 

10.07 Type "To begin operation in the RECEIVE mode, type K = '0'.". 

10.071 Type "To begin operation in the TRANSMIT mode, type K = '1'.". 

10.0711 Demand K. 

10.0712 Type "ERROR. K must be '0' or '1'." if K>1 or K<0. 

10.0713 To step 10.07 if K>1 or K<0. 

10.072 Line. 

10.08 Type "END OF START-UP PROGRAM. ". 

10.081 Do part 2 if K = 0. 

10.082 Do part 100 if K = 1. 



Fig. 28— BLUE/RED start-up program 



9:29 5/10/67 #13 GHN 1423 [10] 
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2.0001 Type "Entering the MESSAGE MONITORING mode.". 

2.0002 Type "Checking for message from GREEN.". 

2.00021 Set X = 0. 

2.0003 Recall item R(2). 

2.00031 Type "No message from GREEN." if k = 0. 

2.00032 Discard item R(2) if k = 1. 

2.0004 Set X = k. 

2.0005 To step 2.001 if k = 0. 

2.0006 Page. 

2.0007 Type "MESSAGE RECEIVED FROM GREEN" if k = 1. 

2.0008 To step 2.23. 

2.001 Recall item R(l). 

2.0011 Discard item R(l) if k = 1. 

2.002 To step 2.2 if k * 0. 

2.003 Do step 2.005 for n = 1(1)5000. 

2.0031 Type "No message from opponent.". 

2.0032 Line. 

2.004 To step 2.0002. 

2.005 Set k = k. 

2.2 Page. 

2.22 Type "MESSAGE RECEIVED FROM OPPONENT.". 

2.23 Type 

2.3 Type part 1 if k * 0. 
2.41 Delete part 1. 

2.5 Set k = 0. 

2.6 File k as item R(l) if X = 0. 

2.61 File k as item R(2) if X = 1. 

2.62 To step 2.0002 if X = 1. 

2.9 Type "END OF MESSAGE.". 
2.901 To step 2.001 if X*0. 

2.91 Type 

2.911 Type "To REPLY to above message, set K = '1',". 

2.912 Type "To continue in MESSAGE Monitoring mode! set K = '0'." 

2.913 Demand K. 

2.914 Do part 100 if K = 1. 

2.915 To step 2.92 if K = 0. 

2.92 Type "Back in message monitoring loop.". 
2.99 To step 2.0002. 



Fig. 29— BLUE/RED message monitoring program 



9:32 5/10/67 #13 GHN 1423 [11] 



r yp e pa^ 

LOO. 002 Type "MESSAGE GENERATION AND TRANSMISSION PROGRAM.". 
100.003 Type 

100.1 Set k = 1. 

100.2 Type "Preface each line of message with a "Part 1" number.". 

100.3 Type "After composing message, type "Go.".". 

L00. 41 Type part 1. 
100.42 Type 

LOO. 43 Type "To make CORRECTIONS, set C = '1', else set C = '0'.". 

100.44 Demand C. 

100.45 To step 100.5 if C = 0. 

100.46 Type "Make CORRECTIONS, then type *Go.'.". 
LOO. 47 Stop if C = 1. 

100.48 Type "To TRANSMIT message, set K = '1'.". 

100.481 Type "To CHECK message again for corrections, set K = '0'.". 

100.482 Demand K. 

100.483 To step 100.41 if K = 0. 

100.484 Line if K = 1. 

100.5 Discard item T(l). 
100.51 Discard item T(2). 

100.6 File k, part 1 as item T(l). 
100.601 File k, part 1 as item T(2). 
100.61 Type "MESSAGE TRANSMITTED.". 

100.7 Delete part 1. 

100.8 Type "To shift to MESSAGE MONITORING mode, set K = *1'.". 
100.8001 Type "To send ANOTHER MESSAGE, set K = '0*.". 
100.801 Demand K. 

100.81 Do part 2 if K = 1. 

100.82 To step 100.001 if K = 0. 



Fig. 30— BLUE/RED message generation and transmission program 
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>pe part 11. 

LI. 01 Type "JOSS Store-and-Forward COM-SYSTEM Start-up Program for GREEN. 

11.02 Type 

11.03 Type "Give item no. for transmitting messages to BLUE.". 
LI. 031 Demand T(l). 

11.032 Type "Give item no. for transmitting messages to RED.". 
LI. 033 Demand T(2). 
LI. 04 Line. 

LI. 05 Type "Give item no. for receiving messages from BLUE to RED.". 
LI. 051 Demand R(l). 

11.052 Type "Give item no. for receiving messages from RED to BLUE.". 
LI. 053 Demand R(2). 

11.07 Type "To begin operation in the RECEIVE mode, set K = '1'.". 
LI. 08 Type "To begin with message to BLUE/RED, set K = '0'.". 
LI. 0801 Demand K. 

LI. 0802 Type "END of GREEN START-UP PROGRAM. ". 
LI. 081 To part 200 if K = 0. 
LI. 082 To part 3 if K = 1. 



Fig. 31— GREEN start-up program 



9:35 5/10/67 #13 GHN 1423 [13] 
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Type part 3. 

3.0001 Type "Entering the MESSAGE MONITORING mode as GREEN.". 

3.00011 Do step 3.00013 for n = 1(1)5000. 

3.00012 To step 3.0002. 

3.00013 Set n = n. 

3.0002 Type "Checking for message from BLUE to RED:". 

3.0003 Recall item R(l). 

3.000U Type "No message from BLUE to RED." if k = 0. 

3.0005 Type _,_ if k = 1. 

3.0006 Type " Message from BLUE to RED:" if k = 1. 
3.00061 Line. 

3.0007 Type part 1 if k = 1. 
3.00O71 Delete part 1 if k = 1. 

3.0008 Type _,_ if k = 1. 
3.000801 To step 3.001 if k = 0. 

3.00081 Set k = 0. 

3.00082 Discard item R(l). 

3.00083 File k as item R(l). 

3.001 Type "Checking for message from RED to BLUE:". 

3.002 Recall item R(2). 

3.003 Type "No message from RED to BLUE." if k = 0. 

3.004 Type , if k = 1. 

3.0041 Type - " - Message from RED to BLUE:" if k = 1. 

3.00411 Line. 

3.005 Type part 1 if k = 1. 
3.0051 Delete part 1 if k = 1. 

3.006 Type _,_ if k = 1. 
3.0069 Line. 

3.007 To step 3.00011 if k = 0. 

3.0071 Set k = 0. 

3.0072 Discard item R(2). 

3.0073 File k as item R(2). 

3.0074 To step 3.00011. 



Fig. 32— GREEN message monitoring program 
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Type part ZOO. 

200.001 Page. 

200.002 Type "GREEN MESSAGE GENERATION AND TRANSMISSION PROGRAM.". 

200.003 Type 

200.1 Set k = 1. 

200.2 Type "To send message to BLUE, set S = '1»; to RED, set S = '0' " 
200.21 Demand S. 

200.3 Type "Preface each line of message with a "Part 1" number.". 
200.31 Type "After composing message, type "Go.".". 

200.4 Stop. 

200.41 Type part 1. 

200.42 Type 

200.43 Type "To make CORRECTIONS, set C = '1', else set C = *0*.". 

200.44 Demand C. 

200.45 To step 200.5 if C = 0. 

200.46 Type "Make corrections, then type "Go.".". 

200.47 Stop if C = 1. 

200.48 Type "To TRANSMIT message, set K = *1\". 

200.481 Type "To CHECK message again for corrections, set K = '0'.". 

200.482 Demand K. 

200.483 To step 200.41 if K * 0. 

200.484 Line if K = 0. 

200.5 Discard item T(l) if S = 1. 
200.51 Discard item T(2) if S = 0. 

200.6 File k, part 1 as item T(l) if S = 1. 

200.61 File k, part 1 as item T(2) if S = 0. 

200.62 Type "MESSAGE TRANSMITTED TO BLUE." if S = 1. 

200.63 Type "MESSAGE TRANSMITTED TO RED." if S = 0. 

200.7 Delete part 1. 

200.8 Type "To shift to GREEN MESSAGE MONITORING mode, set K = '1'." 
200.8001 Type "To send ANOTHER MESSAGE, set K = '0'.". 

200.801 Demand K. 

200.81 Do part 3 if K = 1. 

200.82 To step 200.001 if K = 0. 



Fig. 33— GREEN message generation and transmission program 
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